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ABSTRACT 


An  evaluation  of  the  performance  of  a  SONET  management  system  was  con¬ 
ducted  to  better  understand  its  management  capabilities  due  to  network  disruptions  in  the 
presence  of  a  traffic  load.  This  study  analyzed  the  Cisco  Transport  Manager  (CTM) 
which  manages  a  testbed  of  four  Cisco  ONS 15454  optical  systems.  The  network  was  in¬ 
jected  with  HTTP  and  FTP  traffic  generated  by  the  Spirent  Smartbits  system  installed 
with  TeraMetrics  Gigabit  Ethernet  modules  and  load  calibration  configured  by  the 
Spirent  Avalanche  software.  To  simulate  real-world  situations,  power  disruptions  were 
applied  to  the  network  while  collecting  CTM  traffic  using  Ethereal.  Using  queuing  analy¬ 
sis,  the  arrival  rates  and  service  times  were  computed  for  various  CTM  traffic  compo¬ 
nents  and  a  utilization  for  2500  network  elements  (NE)  extrapolated.  Self-similarity 
analysis  was  performed  and  the  log-variance  was  plotted  to  extract  the  Hurst  values.  Fi¬ 
nally,  the  results  and  findings  were  compared  with  prior  research  for  loading  and  no¬ 
loading  cases.  The  results  of  this  study  are  useful  in  determining  the  maximum  number  of 
network  elements  manageable  in  a  disruptive  environment.  Final  analysis  on  the  effects 
of  link  utilization  on  the  queue  size  showed  that  the  CTM  is  able  to  manage  more  NEs 
when  the  network  is  disrupted.  Unfortunately,  managing  more  NEs  increases  the  queue 
size  even  though  the  utilization  was  found  to  be  0.83  for  5450  NEs.  Consequently,  in  or¬ 
der  to  maintain  a  moderate  queue  size,  the  maximum  number  of  NEs  manageable  was 
found  to  be  2495.  This  value  is  close  to  CISCO’S  specification  of  a  CTM  server  manag¬ 
ing  a  maximum  of  2500  NEs. 
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EXECUTIVE  SUMMARY 


In  today’s  network-centric  warfare,  the  success  of  point-to-point  communications 
hinges  upon  the  survivability  of  the  operations  network.  As  networks  grow  and  more  ser¬ 
vices  are  introduced,  managing  the  entire  network  becomes  a  daunting  task.  Deploying  a 
super  network  management  system  or  a  manager  of  managers  may  be  a  solution  but 
without  the  necessary  tools  to  analyze  and  predict  performances,  it  could  result  in  pre¬ 
cious  time  and  revenue  wasted  as  these  advanced  network  management  tools  are  very  ex¬ 
pensive. 

This  study  investigated  the  performance  of  the  Cisco  Transport  Manager  (CTM 
version  4.6)  in  managing  a  Synchronous  Optical  Network  (SONET)  operating  under  ex¬ 
ternal  factors  of  network  loading  and  power  disruptions.  Using  empirical  statistical  meth¬ 
ods,  the  effect  of  power  disruptions  on  the  SONET  management  traffic  is  analyzed.  As 
SONET  systems  are  configured  in  a  ring  topology,  traffic  could  be  routed  by  another  path 
when  one  of  the  optical  systems  is  down. 

The  CTM  was  deployed  in  an  IP  network  and  configured  to  manage  four  units  of 
Cisco  optical  transport  systems,  known  as  ONS 15454,  which  are  installed  in  the  Ad¬ 
vanced  Network  Laboratory  of  the  Naval  Postgraduate  School. 

The  optical  systems  are  managed  via  its  192-kbps  Section  Data  Communication 
Channel  (SDCC)  which  is  provisioned  in  the  fiber  links.  Although  Cisco  has  specified 
that  the  CTM  is  able  to  manage  a  maximum  of  2500  NEs,  the  performance  may  differ 
under  different  network  conditions.  Prior  studies,  [1 1]  and  [12],  have  shown  that  the 
maximum  numbers  of  NEs  manageable  are  1027  for  a  no-traffic  loading  network,  and 
1552  for  a  fully  loaded  network.  The  latter  result  is  interesting  as  it  was  expected  that  the 
number  of  NEs  manageable  should  drop  due  to  higher  intensity  of  network  traffic. 

The  load  traffic  of  this  thesis  was  generated  by  the  Spirent  Smartbits  6000  hard¬ 
ware  data  generator  which  generates  HTTP  and  FTP  packets  configured  using  Spirent 
Smartbits  Avalanche  software.  The  duration  of  the  traffic  was  configured  to  run  for  ten 

xvii 


days.  The  CTM  management  traffic  was  collected  using  an  open  source  packet  sniffer 
called  Ethereal  which  collects  the  data  packets  arriving  and  leaving  the  CTM  server.  In 
particular,  the  management  traffic  of  interest  were  Socks,  SNMPv2  and  related  TCP  data 
packets  which  are  collectively  referred  to  as  CTM  Ethernet  traffic. 

The  analysis  was  performed  using  statistical  methods  by  modeling  the  interarrival 
times  and  packet  sizes  as  random  variables  based  on  the  CTM  data  traffic  collected. 
Queuing  theory  was  applied  to  compute  the  arrival  rates  and  service  times  which  enable 
the  utilization  to  be  derived  and  subsequently  extrapolated  to  estimate  the  utilization  of 
2500  NEs.  Self-similarity  analysis  was  also  performed  to  extract  the  Hurst  values  of  the 
CTM  traffic.  Finally,  the  maximum  number  of  NEs  was  deduced  using  the  Norros  model 
which  defines  the  relationship  between  utilization  and  queue  size. 

From  the  traffic  analysis,  it  was  observed  that  the  Socks  and  SNMPv2  traffic  de¬ 
creases  when  the  SONET  network  is  loaded  and  disrupted  by  NE  power  failures.  Though 
lower,  the  total  Ethernet  traffic  was  about  20%  higher  compared  to  the  case  when  the  net¬ 
work  was  loaded  but  not  disrupted.  While  the  decrease  in  Socks  and  SNMPv2  was  due  to 
the  NE  offline,  the  increase  in  Ethernet  traffic  was  deduced  to  be  generated  by  the  CTM 
server  due  to  polling  of  the  NEs. 

Further  analysis  on  the  interarrival  time  statistics  revealed  that  the  means  are 
higher  compared  to  no-disruption  case.  The  higher  mean  interarrival  times  suggests  that 
the  arrival  rate  is  lower  which  is  consistent  with  the  fact  that  the  distribution  graphs  ex¬ 
hibit  a  faster  decay  rate  compared  to  the  no-disruption  case.  The  statistical  analysis  on  the 
packet  size  statistics  revealed  that  the  distribution  varies  only  slightly  when  compared  to 
the  no-disruption  case.  Despite  the  minute  differences,  the  Ethernet  packet  mean  packet 
size  was  lower  due  to  averaging  over  more  packets  collected  for  the  loading/disruption 
case.  Interestingly  enough,  Socks  and  SNMPv2  packet  size  means  were  lower  too,  al¬ 
though  the  number  of  packets  were  lower  compared  to  the  loading  case. 

The  self-similarity  analysis  revealed  that  Socks  traffic  for  the  loading/disruption 
case  was  less  self-similar  compared  to  loading  case,  while  more  self-similar  compared  to 
no-loading  case.  The  SNMPv2  traffic  Hurst  value  drops  below  0.5  which  indicated  that  it 
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does  not  possess  an  exponential  distribution  due  to  disruption.  The  combined  Socks  and 
SNMPv2  had  a  Hurst  value  which  fell  in  between  the  loading  and  no-loading  cases,  sug¬ 
gesting  the  dominant  effect  of  Socks  traffic  over  SNMPv  within  the  SDCC  channel.  Nev¬ 
ertheless,  the  CTM  Ethernet  traffic  was  less  self-similar  compared  to  both  loading  and  no 
loading  cases. 

Final  analysis  on  the  effects  of  link  utilization  on  the  queue  size  showed  that  the 
CTM  is  able  to  manage  more  NEs  when  the  network  is  disrupted.  Unfortunately,  manag¬ 
ing  more  NEs  increases  the  queue  size  even  though  the  utilization  was  found  to  be  0.83 
for  5450  NEs.  Consequently,  in  order  to  maintain  a  queue  size  of  1,  for  a  utilization  of 
0.38,  the  maximum  number  of  NEs  manageable  was  found  to  be  2495.  This  value  is  close 
to  CISCO’S  specification  of  CTM  server  managing  a  maximum  of  2500  NEs. 

Study  of  network  loading  coupled  with  power  disruptions  is  an  important  research 
area  which  will  be  useful  for  high-speed  computer  networks  administrators.  The  results 
and  findings  of  this  thesis  will  benefit  the  SONET  network  administrators  by  increasing 
their  awareness  of  the  limitations  of  SONET  network  management  systems.  Further,  this 
research  provides  the  ability  to  optimize  the  deployment  of  SONET  optical  systems  in 
order  to  tackle  network  problems  associated  with  network  loading  and  power  disruptions. 
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I. 


INTRODUCTION 


A.  MOTIVATION 

Systems  adhering  to  the  SONET/SDH  standards  have  been  widely  deployed  as 
the  fiber  optics  transport  backbone  of  many  telecommunications  service  providers’  net¬ 
works.  SONET  was  first  introduced  by  Bellcore  (now  Tecordia)  in  the  mid  1980’s  as  the 
optical  transport  technology  to  support  high  capacity  transport  and  has  become  the  de- 
facto  standard  in  the  industry  [1],  SONET  is  a  very  reliable  transport  system  and  until  this 
date  no  suitable  technology  is  able  to  replace  it.  The  next  generation  SONET  is  built  on 
Wavelength-Division  Multiplexing  (WDM)  technology  which  provides  much  higher  ca¬ 
pacity  [2],  This  has  occurred  in  tandem  with  the  emerging  field  of  Traffic  Engineering 
(TE)  which  has  become  an  important  research  area  in  optimizing  and  protecting  next- 
generation  optical  networks  [3], 

SONET  stands  for  Synchronous  Optical  Network  which  is  defined  by  the  Ameri¬ 
can  National  Standards  Institute  (ANSI)  for  synchronous  digital  networks  using  optical 
media  in  the  North  America  [4],  Its  international  equivalent  is  Synchronous  Digital  Hier¬ 
archy  (SDH)  which  is  the  European  standard  defined  by  the  ITU.  In  a  typical  deployment 
of  the  SONET  system,  a  dedicated  control  channel  known  as  the  Section  Data  Communi¬ 
cations  Channel  (SDCC)  is  provisioned  as  part  of  overhead  in  all  the  fiber  links.  This  en¬ 
ables  the  SONET  management  system  to  communicate  with  the  network  elements  which 
are  deployed  geographically  apart. 

In  real-world  situations,  disruptions  or  network  outages  due  to  power  failures  and 
fiber  disconnections  are  often  unavoidable.  Although  there  has  been  research  on  the 
measurement  and  modeling  of  computer  networks  with  self-similar  nature  -  specifically 
in  the  areas  of  router  and  web  traffic  [5],  Internet  traffic  [6],  wireless  traffic  [7],  and 
Ethernet  traffic  [8]  -  the  effects  of  network  loading  coupled  with  power  disruptions  have 
not  been  fully  investigated.  Furthermore,  highly  self-similar  traffic  could  cause  queuing 
delays,  increase  packet  drop  rates  and  prolonged  periods  of  congestion  [9],  As  such,  net¬ 
work  loading  coupled  with  power  disruptions  is  an  important  research  area  useful  for 
high-speed  computer  networks  administrators. 
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Although  SONET  has  the  advantage  of  re-routing  traffic  via  the  next  available  op¬ 
tical  path,  it  is  not  known  whether  the  utilization  rate  of  SDCC  channel  would  be  in¬ 
creased.  Furthermore,  it  is  known  that  current  SONET  management  systems  in  the  mar¬ 
ket  employ  several  management  protocols  to  manage  their  network  elements  [10],  and 
these  different  types  of  management  traffic  behave  differently  within  the  network.  It  is 
important  to  understand  whether  disruption  would  affect  the  number  of  network  elements 
manageable  or  cause  bottlenecks  within  the  network,  due  to  an  increase  in  management 
traffic.  More  importantly,  it  is  imperative  to  investigate  whether  the  management  server 
is  able  to  handle  the  possible  increase  in  management  traffic  due  to  network  disruptions. 

Very  often,  the  SONET  network  is  designed  based  on  the  vendors’  specification 
of  the  maximum  number  of  network  elements  manageable.  Over  years  of  operation,  net¬ 
work  sizes  expand  and  more  nodes  are  added.  Even  though  the  total  number  of  network 
elements  is  kept  well  within  the  maximum  stated  by  the  vendor,  we  do  not  know  to  what 
extent  introducing  more  nodes  would  affect  the  utilization  of  the  SDCC  link.  Further¬ 
more,  we  do  not  know  how  disruptions  within  the  network  would  affect  the  SDCC  and 
whether  it  would  cause  the  SDCC  link  utilization  to  increase  or  decrease. 

B.  THESIS  OBJECTIVE 

Armed  with  these  questions  in  mind,  it  is  important  to  investigate  the  performance 
of  the  SONET  management  system,  to  analyze  the  effects  of  disruptions  using  statistical 
means,  and  to  derive  the  optimal  number  of  network  elements  manageable  with  real- 
world  factors  taken  into  consideration.  This  is  an  important  research  area  as  the  results 
and  findings  of  this  study  would  be  useful  and  valuable,  not  only  to  the  industry  as  well 
as  the  military  in  deploying  SONET  systems,  but  also  to  facilitate  the  understanding  of 
the  underlying  intricacies  of  the  network  management  paradigm  in  the  fast-paced  IT 
world. 

For  the  purpose  of  this  study,  a  Cisco  SONET  system  was  used  as  a  platform  to 
study  the  performance  and  effectiveness  of  a  network  management  tool  in  managing  the 
optical  systems.  Under  this  study,  the  network  elements  are  the  Cisco  ONS 15454  optical 
transport  systems  while  the  element  management  system  is  the  Cisco  Transport  Manager 
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(version  4.6).  The  CTM’s  server  management  performance  was  investigated  by  simulat¬ 
ing  network  disruption  within  the  fiber  network  under  the  conditions  of  injected  data  traf¬ 
fic  within  the  network.  Data  analysis  was  performed  on  the  data  packets  collected  at  the 
CTM  server  and  statistical  analysis  was  performed  to  determine  the  number  of  manage¬ 
able  NEs  under  loading  of  network  with  simulated  disruption. 

C.  PRIOR  WORK 

In  recent  research  by  Lim  [11],  traffic  analysis  was  carried  out  on  the  manage¬ 
ment  traffic  between  the  CTM  server  and  ONS 15454  without  loading  or  disruption.  It 
was  found  that  the  number  of  manageable  NEs  was  1027.  A  later  study  by  Ng  [12]  car¬ 
ried  out  on  the  same  network,  with  actual  traffic  loading  of  the  fiber  network,  determined 
that  the  number  of  manageable  NEs  to  be  1552. 


D.  THESIS  ORGANIZATION 

This  chapter  has  presented  the  motivation  of  this  study  and  the  thesis  objectives. 
Prior  related  work  was  also  discussed.  The  next  chapter  introduces  the  Cisco  SONET  sys¬ 
tem  overview  and  the  network  management  system.  Chapter  III  discusses  the  laboratory 
setup  of  the  equipment  for  the  data  collection  of  the  CTM  management  traffic.  Chapter 
IV  presents  the  statistical  techniques  employed  in  the  analysis  of  the  data  collected. 
Chapter  V  discusses  the  results  and  findings  from  the  statistical  analysis.  Last  but  not 
least,  Chapter  VI  summarizes  the  research  work  with  proposals  for  future  work. 
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II.  SONET  NETWORK  MANAGEMENT  SYSTEM  OVERVIEW 

A.  CHAPTER  OVERVIEW 

This  chapter  presents  the  Cisco  ONS 15454  system  overview,  discussing  the  fea¬ 
tures  of  the  ONS  15454  optical  system  as  a  multiservice  transport  platform.  The  network 
management  tools  of  Cisco  Transport  Client  (CTC),  Cisco  Transport  Manager  Client  and 
Server  are  also  described.  In  addition,  a  brief  discussion  on  the  Simple  Network  Man¬ 
agement  Protocol  (SNMP)  is  presented. 


B.  INTRODUCTION 

As  optical  networks  become  very  large,  an  efficient  network  management  system 
is  needed  to  manage  resources.  Telecommunications  network  management  is  an  impor¬ 
tant  area  in  the  telecommunication  industry  as  operators  are  concerned  with  revenue,  ser¬ 
vice  assurance,  maintaining  Service  Level  Agreements  (SLA),  and  keeping  operations 
costs  low.  Understanding  the  market  concern,  CISCO  has  introduced  the  CISCO  Trans¬ 
port  Manager  (CTM),  the  industry’s  most  advanced  optical  network  management  system 
[13].  In  compliance  with  the  Telecommunications  Management  Network  (TMN)  frame¬ 
work  [14],  the  CTM  sits  within  the  Network  Management  Layer  (NML)  and  the  Element 
Management  Layer  (EML).  Essentially,  it  is  a  Network  Element  (NE)  manager,  which 
incorporates  industry  standard  interfaces  for  managing  the  optical  devices,  and  provides 
management  functions,  operations,  provisioning  and  maintenance  of  the  entire  optical 
network. 


C.  CISCO  ONS15454  SYSTEM  OVERVIEW 

The  Cisco  ONS  15454  is  a  SONET  optical  network  system  which  provides  a  mul¬ 
tiservice  provisioning  platform.  It  supports  Time  Division  Multiplex  standards  for  inter¬ 
faces  such  as  DS-1,  DS-3,  and  EC-1,  and  data  interfaces  for  Ethernet  and  Gigabit 
Ethernet  [13].  The  optical  transport  interface  supports  OC-3  to  OC-192  with  integrated 
dense  WDM  (DWDM). 
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Within  the  Advanced  Network  Laboratory  of  Naval  Postgraduate  School,  four 
ONS 15454  optical  systems  are  installed  in  a  ring  configuration  simulating  the  locations 
of  Pacific  Grove,  Carmel,  Salinas  and  Monterey,  as  depicted  in  Figure  1.  Note  that  the 
dotted  circle  represents  the  SDCC  link  which  supports  the  transfer  of  the  management  in¬ 
formation.  The  Monterey  optical  system  is  connected  to  the  IP  network  where  the  Cisco 
Transport  Controller  (CTC)  Client,  the  Cisco  Transport  Manager  (CTM)  server  and  the 
CTM  Client  are  located.  The  CTC  Client  is  installed  and  configured  to  run  on  a  Windows 
2003  server.  The  CTM  Client  is  installed  on  a  Windows  XP  machine  while  the  CTM 
Server  is  installed  on  Solaris  server.  Both  the  CTM  Client  and  Server  used  in  this  labora¬ 
tory  setup  are  version  4.6.  The  following  sections  describe  the  respective  software  in  de¬ 
tail. 


PACIFIC  GROVE  MONTEREY 


Figure  1.  CISCO  ONS  15454  and  SONET  Network  Management  System 

Setup  (After  Ref.  [11].) 


1.  Cisco  Transport  Client  (CTC) 

The  Cisco  Transport  Client  (CTC)  is  a  Windows  web-based  Java  program  in¬ 
stalled  on  a  Windows  2003  server  [15].  It  is  used  to  monitor  the  health  status  and  alarms 
of  the  ONS  15454  nodes.  It  also  provides  provisioning  capabilities  for  configuration  of 
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the  ONS 15454  expansion  cards  to  provision  the  fiber  links  and  the  Ethernet  connections 
as  depicted  in  Figure  2.  It  communicates  with  the  CTM  Server  continuously  to  monitor 
the  health  status  and  to  update  the  network  provisioning  configurations. 
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Figure  2.  CTC  management  interface 


2.  Cisco  Transport  Manager  Client  (CTM  Client) 

The  CTM  Client  is  a  Windows  Java-based  program  installed  on  a  Windows  XP 
machine  [15].  It  is  used  to  communicate  with  the  CTM  server  for  all  activities  related  to 
user  access  and  administration,  network  configuration  and  management  services  configu¬ 
ration.  Figure  3  shows  the  CTM  Client  management  interface  for  the  Carmel  optical  sys¬ 
tem.  The  figure  shows  that  Slot  3,  7  and  8  of  the  optical  system  are  provisioned  for 
Ethernet  interface,  OC12  circuit  and  two  control  channels,  respectively. 
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Figure  3.  CTM  Client  management  interface 


3.  Cisco  Transport  Manager  Server  (CTM  Server) 

The  CTM  server  is  the  Element  Management  System  (EMS)  for  the  ONS 15454 
fiber  network  [15].  It  manages  all  fiber  optic  network  elements  and  stores  the  configura¬ 
tions  within  its  Oracle  8i  database  system  which  is  installed  on  the  same  Solaris  machine 
as  the  CTM.  The  CTM  server  issues  commands  and  downloads  configuration  and  per¬ 
formance  information  from  every  ONS  15454  connected  to  the  network. 


4.  The  Section  Data  Communications  Channel  (SDCC) 

The  SDCC  forms  the  heart  of  the  SONET/SDH  management  transport  functions. 
Essentially,  the  SDCC  is  a  dedicated  192 -kbps  channel  which  is  included  in  the 
SONET/SDH  overhead  and  conveys  the  management  information  between  the  optical 
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systems  and  the  network  management  system  [3],  The  SDCC  conveys  all  management 
traffic  which  are  Socks  and  SNMPv2.  The  SDCC  link  is  illustrated  as  the  dotted  line 
within  the  SONET  ring  in  Figure  1. 

D.  SIMPLE  NETWORK  MANAGEMENT  PROTOCOL  (SNMP) 

SNMP  is  a  distributed  network  management  protocol  used  to  manage  network 
elements  which  are  connected  within  an  IP  network.  Currently,  there  are  three  versions 
defined  by  the  IETF  [16],  The  first  version,  SNMPvl,  supports  server  commands  “Get,” 
“GetNext”  and  “Set,”  and  agent  commands  “Get-Response”  and  “Trap.”  SNMPvl  is  in¬ 
efficient  as  it  retrieves  the  management  information  “entry-by-entry”  and  is  thus  time 
consuming  and  bandwidth  inefficient.  The  second  version,  SNMPv2,  implements  two 
additional  commands,  “GetBulk”  and  “Inform”,  as  well  as  enhances  the  protocol  opera¬ 
tions.  The  “GetBulk”  command  is  used  to  efficiently  retrieve  the  entire  record  of  man¬ 
agement  information  from  the  network  elements.  Lastly,  SNMPv3  adds  security  and  al¬ 
lows  remote  configuration  capabilities  in  addition  to  the  previous  versions. 

Currently,  the  CTM  server  supports  SNMPv2  for  managing  the  ONS 15454  opti¬ 
cal  switches  which  are  connected  within  the  IP  network. 

E.  SUMMARY 

In  this  chapter,  the  Cisco  SONET  optical  transport  system  overview  has  been  pre¬ 
sented.  A  brief  introduction  of  the  SNMP  protocol  was  also  discussed.  The  next  chapter 
describes  the  laboratory  setup  and  the  configuration  details  of  Cisco  SONET  system. 
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III.  LABORATORY  SETUP  AND  PROCEDURES 


A.  CHAPTER  OVERVIEW 

This  chapter  presents  the  laboratory  setup  of  the  Cisco  SONET  system  describing 
the  configurations  of  the  Cisco  ONS 15454  optical  system  and  the  Cisco  Transport  Man¬ 
ager.  The  procedures  for  configuring  the  Spirent  SmartBits  6000  traffic  generator  and  for 
load  calibration  of  the  Spirent  Avalanche  software  are  also  explained.  The  process  of  ap¬ 
plying  disruptions  to  the  SONET  network  is  described.  Finally,  the  CTM  data  traffic  col¬ 
lection  procedure  is  presented. 


B.  DEFINING  THE  TEST  SCENARIO 

The  objective  of  this  study  was  to  investigate  the  performance  of  the  SONET 
management  system  under  loading  with  network  disruption.  In  order  to  simulate  real 
world  conditions,  the  SONET  network  was  loaded  with  HTTP  and  FTP  traffic  to  simulate 
users  accessing  web  servers  and  establishing  FTP  sessions  for  data  transfer.  For  disrup¬ 
tions  within  the  network,  one  or  more  ONS  15454  optical  systems  were  switched  off  and 
turned  back  on  a  couple  of  times  each  day.  This  manual  switching  process  was  repeated 
over  a  10-day  data  collection  period.  The  entire  process  would  be  sufficient  to  simulate 
network  loading  with  network  outages  manually  induced  on  a  worst  case  basis. 

C.  CONFIGURATION  OF  LABORATORY  EQUIPMENT 

The  following  describes  the  configurations  of  the  respective  laboratory  compo¬ 
nents,  the  traffic  generation  and  data  collection  processes. 


1.  Laboratory  Setup  of  Equipment 

The  ONS  15454  optical  systems  and  CTM  management  system  were  installed  and 
set  up  by  Lim  [11],  The  ONS  15454  nodes  are  connected  in  a  ring  with  one  of  the 
switches  connected  to  the  IP  network,  as  shown  in  Figure  4.  Each  ONS  15454  is  installed 
with  a  ML  1000  card  which  provides  Gigabit  Ethernet  connection  to  the  LAN.  Only  one 
IP  connection  is  necessary  as  the  ONS  15454  optical  systems  are  interconnected  by  the 
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SDCC  channel  which  is  provisioned  in  the  fiber  links.  The  SDCC  channel  acts  as  the 
control  channel  and  bridges  to  the  IP  network  so  that  the  CTM  server  can  communicate 
with  the  optical  systems  via  this  channel.  Another  reason  that  the  network  was  set  up  in 
this  manner  was  to  simulate  the  different  geographical  locations  at  which  these  optical 
switches  are  installed. 

CTC  CLIENT  CTM  CLIENT  CTM  SERVER 


Windows  2003  server  WindowsXP  Solaris 

1 92. 1 68.200.7  1 92. 1 68.200. 11  1 92. 1 68.200. 1 0 


Figure  4.  Laboratory  Setup  of  the  Cisco  SONET  system  and 
Spirent  traffic  generator  (After  Ref.  [12].) 


The  SmartBits  6000  chassis  developed  by  Spirent  Communications  was  con¬ 
nected  to  the  IP  network.  It  was  installed  with  two  TeraMetrics  Gigabit  Ethernet  modules 
which  provide  the  optical  interfaces  for  connection  to  the  ML  1000  Gigabit  interface  cards 
on  the  ONS 15454  chassis. 
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2.  Configuring  the  ML1000  Interfaces 

The  ML  1000  interface  card  supports  Gigabit  Ethernet  access  to  allow  bridging  the 
LAN  network  to  the  optical  transport  network.  Each  ONS 15454  was  installed  with  this 
card  which  was  connected  to  the  TeraMetrics  Gigabit  Ethernet  interfaces  on  the  Spirent 
SmartBits  6000  chassis  for  data  traffic  to  be  injected  into  the  SONET  network.  The  IP 
addresses  of  the  POS  and  Gigabit  Ethernet  interfaces  of  every  ONS  15454  card  were  con¬ 
figured  by  Ng  [12]  based  on  the  configurations  depicted  in  Table  1. 


ONS15454 

Card 

Gigabit  Ethernet 
Interface 

POSO 

POS1 

Salinas 

192.168.90.183 

192.168.1.153 

192.168.2.163 

Monterey 

192.168.100.183 

192.168.1.163 

192.168.2.163 

Pacific  Grove 

192.168.110.183 

192.168.1.173 

192.168.2.173 

Carmel 

192.168.120.183 

192.168.1.183 

192.168.2.183 

Table  1 .  IP  addresses  of  the  O' 

NS  15454  Packet-Over-SONET  and 

Gigabit  Ethernet  interfaces  (From  Ref.  [12].) 


3.  Configuring  the  Spirent  Smartbits  Traffic  Generator 

In  order  to  inject  real  traffic  into  the  optical  network,  a  hardware  and  software 
setup  using  the  Spirent  Communications  systems  were  required  as  shown  in  Figure  5. 

The  Spirent  SmartBits  6000  chassis  was  installed  with  two  TeraMetrics  LAN-3321 A  Gi¬ 
gabit  Ethernet  interface  cards  [17].  The  SmartBits  6000  chassis  and  the  TeraMetrics  cards 
were  configured  using  the  SmartBits  Avalanche  software  via  the  IP  connection  as  shown 
in  Figure  4. 


4.  Configuring  the  SmartBits  6000  Chassis 

The  TeraMetrics  modules  were  configured  with  the  settings  shown  in  Table  2. 
Note  that  the  TeraMetrics  modules  have  to  be  configured  in  the  same  subnet  with  the  Gi¬ 
gabit  Ethernet  interface  cards  of  the  ONS  15454  optical  systems. 
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ONS15454  Chassis 


Servers  and  Qients  dusters  configured 
via  Spirent  Avalanche  Software 


Server  Ouster 


Qient  Ouster 


Figure  5.  Connections  between  SmartBits  6000  and  ONS15454  chassis,  and 
configuration  of  servers/clients  clusters  of  the  TeraMetrics  Gigabit 

Ethernet  modules 


5.  Load  Calibration  using  the  SmartBits  Avalanche  Software 

The  SmartBits  Avalanche  software  [18]  was  used  to  configure  the  following 


items: 


a.  Number  of  servers  and  clients 


b.  Types  of  servers  (HTTP,  FTP,  SMTP,  etc.) 


c.  Length  of  data  traffic  injection 


Each  TeraMetrics  module  features  two  fiber  interface  ports  which  are  connected 
to  the  ML1000  cards  on  the  ONS15454  chassis.  One  of  the  TeraMetrics  fiber  interface 
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ports  is  configured  as  a  server-LAN  while  the  other  is  a  client-LAN.  The  second 
TeraMetrics  interface  card  is  configured  in  a  similar  manner.  Table  2  shows  the  configu¬ 
ration  of  the  TeraMetrics  modules  and  the  connection  to  which  ONS 15454  chassis.  Fig¬ 
ure  6  shows  the  configuration  of  100  clients  and  Figure  7  shows  the  association  of  the 
client-LANs  with  the  respective  TeraMetrics  modules. 


TeraMetric  Mod¬ 
ule  IP  address 

Design¬ 
ated  as 

Types  of 

servers/ 

clients 

IP  addresses  config¬ 
ured  in  Spirent  Ava¬ 
lanche  Software 

Connected  to 

which 

ONS15454 

192.168.200.153:0 
Card  1 ,  port  0 

Server- 

LAN 

HTTP 
and  FTP 

servers 

192.168.100.1  (HTTP) 

192.168.100.2  (FTP) 

192.168.100.3  (HTTP) 

Monterey 

192.168.200.153:1 
Card  1,  port  1 

Server- 

LAN 

HTTP 
and  FTP 

servers 

192.168.110.1  (HTTP) 

192.168.110.2  (HTTP) 

192.168.110.3  (FTP) 

Pacific  Grove 

192.168.200.154:0 
Card  2,  port  0 

Client- 

LAN 

100  Cli¬ 
ents 

192.168.90.1-100 

100  Clients 

Salinas 

192.168.200.154:1 
Card  2,  port  1 

Client- 

LAN 

100  Cli¬ 
ents 

192.168.120.1-100 

100  Clients 

Carmel 

Table  2.  Configuration  of  the  TeraMetrics  modules  the  connections 
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|Ei  fr--ii  ii-Llir  :  n-1 


6.  Load  Calibration 

Once  the  TeraMetric  modules  were  configured,  the  data  traffic  load  calibration 
was  configured  using  the  model  shown  in  Figure  8.  Using  the  Spirent  Avalanche  soft¬ 
ware,  four  phases  of  the  loading  process  were  configured.  Phase  I  is  the  ramping  up  of 
the  data  traffic  to  a  height  of  Anumber  of  connections.  Phase  II  is  known  as  stepping 
whereby  the  number  of  connections  is  increased  by  steps  of  A  from  A  to  4A.  Phase  III  is 
known  as  the  sustaining  stage  whereby  the  maximum  number  of  connections  are  held  for 
a  period  of  time.  Finally  at  Phase  IV,  the  ramp  down  process,  the  number  of  connections 
are  brought  to  zero. 
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Actual  Load 


Figure  8.  Diagram  of  the  data  traffic  generation  test  phases  (From  Ref.  [13].) 


Based  on  the  requirement  of  10-day  data  collection  period,  the  settings  in  Table  3 
were  configured  in  the  “Load”  submenu  of  the  Spirent  Avalanche  software. 


Phases 

Settings 

Values 

Units 

Phase  1 :  Ramp  up 

Time 

300 

Seconds 

Height 

50 

Connections 

Phase  2:  Stepping 

Step  ramp  time 

300 

Seconds 

Step  steady  time 

215,625 

Seconds 

Step  height 

50 

Connections 

Number  of  steps 

3 

Phase  3:  Holding 

Holding  time 

215,625 

Seconds 

Holding  height 

200 

Phase  4:  Ramp  down 

Minimum  finishing 
time 

300 

Seconds 

Total  time 

300  +  300  x  3  +  (215625)  x  3  +  215625  +  300 
=  864,000  seconds  or  10  days 

Table  3.  Load  calibration  settings  of  the  Spirent  Avalanche  software 


7.  Configuring  the  SONET  Network  Management  System 

In  order  to  ensure  that  the  CTM  management  traffic  is  flowing  through  the  SDCC 
link,  the  following  additional  steps  have  to  be  taken. 
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Using  the  CTC  client,  each  ONS 15454  was  configured  with  SNMP  destination 
address  of  192.168.200.10  and  port  number  162  so  that  SNMP  traps  could  be  sent  to  the 
CTM  server.  Port  163  is  used  for  CTM  server  communicating  with  ONS15454.  Figure  9 
shows  a  snapshot  of  the  SNMP  trap  setting  for  Pacific  Grove.  The  IP  address  of  the  CTM 
server  is  entered  with  the  UDP  port  number  set  to  162. 

Next,  the  CTM  Client  is  initiated  to  ensure  that  the  management  services  and 
processes  are  configured.  As  depicted  in  the  CTM  Client  “NEService”  submenu  window 
of  Figure  10,  the  ONS  15454  “green  arrow”  is  up  signifying  that  the  management  services 
are  running  on  the  CTM  server.  This  is  the  management  information  conveyed  in  the 
SDCC  link. 


Figure  9.  Snapshot  SNMP  traps  settings  in  the  CTC  Client  interface 
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Figure  10.  Snapshot  of  management  services  and  processes  settings  in  the  CTM 

Client  interface 


Lastly,  on  the  Solaris  machine  where  the  CTM  server  is  running,  the  command 
“showctm”  is  executed  to  display  the  management  processes  which  have  been  configured 
to  run.  Figure  1 1  shows  the  snapshot  from  the  Solaris  machine  which  displays  the  proc¬ 
esses  of  “SnmpTrapService,”  “SMService,”  and  “NEService”  running  on  the  CTM 
server. 


*  showctnt 


CTM  Processes  for  TransportManatger  Server  version  4.5.0.520 

root  45?  0,0  0,411 67 2  7290?  s  Mar  01  0:00  /opt Jc  1  scot ranspo rtManage rserve r/b  1  h/ctms e rver 

root  47?  0,0  0 . 821 840157S4  ?  S  Rar  01  5:22  /opt/Ci  scoT ranspo rt Manager Server Zb i  n/CTMServer 


root 

661 

0.5 

5,121 000095?  44  ? 

S  F^ar  01 

SrsmpT  rapServi  ce 

root 

496 

0.1 

7.2217720152336 

? 

5 

Mar 

01 

SMService 

root 

653 

0,0 

1 6.3330232323632 

1 

S 

Mar 

01 

QMS 1 5 45  4/OMS 15  3  27 /ONS 15  600  M£Se rv 1 CS- 2 1 

root 

675 

0,0 

8.3224200163848 

7 

£ 

Mar 

01 

ONS 15  45  4 /OHS  1  53  27  PMSe  rv i c  e- 2 

root 

463 

0.0 

0.2  S536  33S2 

? 

S 

Mar 

01 

Apache  neb  Server 

oracl  e 

309 

0,0 

7 .4175030146332 

7 

s 

Mar 

01 

1  11  QracleCTM4_6 

Apache  web  server 

oracl  e 

319 

0.0 

7 .4175040146300 

7 

s 

Mar 

01 

1:12  oracleCTM4_6 

Apache  web  server 

o  rated  e 

jf  1 

323 

0.0 

7.41  7  49  341  46SOO 

? 

s 

Mar 

01 

1:12  orac'1eCTM4  6 

Apache  Web  Server 

Figure  1 1 .  Snapshot  of  CTM  management  processes 
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8.  Configuring  Ethereal 

After  the  SONET  network  and  the  Spirent  traffic  generator  have  been  set  up,  the 
data  packets  of  the  CTM  server  are  ready  to  be  collected.  An  open  source  data  packet 
sniffer  known  as  Ethereal  is  installed  on  the  Solaris  server  to  collect  the  CTM  manage¬ 
ment  traffic.  Figure  12  shows  a  snapshot  of  the  Ethereal  application  running  on  the  CTM 
server.  It  captures  all  incoming  and  outgoing  packets  at  the  CTM  server  and  records  the 
arrival  times  and  packet  lengths  of  all  the  packets. 
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Figure  12.  Snapshot  of  Ethereal  application  running  on  the  Solaris  machine 

9.  Power  Disruption  Simulation 

The  Ethereal  application  is  executed  to  commence  with  the  CTM  data  traffic  col¬ 
lection  process  which  is  immediately  followed  by  initiating  the  traffic  generation  from 
the  Spirent  Avalanche  application.  Figure  13  shows  the  routing  of  traffic  from  Carmel  to 
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Pacific  Grove  when  Salinas  is  down.  During  the  10-day  period,  the  ONS 15454  desig¬ 
nated  as  Salinas  was  switched  off  once  a  day  for  the  first  5  days.  Each  time  the 
ONS  15454  was  switched  on,  the  average  network  recovery  time  was  about  7  minutes. 
For  the  remaining  5  days,  both  Salinas  and  Carmel  were  switched  off  2-3  times  each  day. 


'  Traffic  routing 

PACI FIC  GROVE  via  this  path 


MONTEREY 


CARMEL 

192.168.200.210 


SALINAS 

192.168.200.213 


Figure  13.  Power  Disruption  simulation  of  Salinas  and  traffic  routing 


During  the  process,  the  times  at  which  the  specific  ONS  15454  were  switched  off 
were  recorded  and  the  duration  of  the  outage  noted.  Table  4  shows  the  complete  log  re¬ 
corded  in  this  study.  Logging  down  the  outage  durations  enables  the  network  availability 
to  be  estimated. 

From  Table  4,  by  taking  into  consideration  that  the  optical  system  takes  about  7 
minutes  to  synchronize  the  traffic  flow,  the  network  availability  is  estimated  to  be  about 
97.16%.  Thus  the  network  outage  is  about  2.84%. 
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Date 

Time 

Optical  system 
switched  off 

Duration  of  power 
disruption  (min) 

Jan  26 

1700 

Test  Started 

1730 

1730 

1 

Jan  27 

0800 

Salinas 

1 

Jan  28 

1345 

Salinas 

1 

Jan  29 

0730 

Salinas 

1 

Jan  30 

0830 

Salinas 

1 

Jan  31 

0810 

Salinas,  Carmel 

30 

1115 

Salinas,  Carmel 

15 

1335 

Salinas,  Carmel 

15 

Feb  1 

0820 

Salinas,  Carmel 

30 

0920 

Salinas,  Carmel 

20 

1105 

Salinas,  Carmel 

30 

1715 

Salinas,  Carmel 

30 

Feb  2 

0915 

Salinas,  Carmel 

40 

1200 

Salinas,  Carmel 

40 

1445 

Salinas,  Carmel 

1 

Feb  3 

0915 

Salinas,  Carmel 

1 

1105 

Salinas,  Carmel 

1 

1405 

Salinas,  Carmel 

1 

Feb  4 

0900 

Salinas,  Carmel 

1 

1200 

Salinas,  Carmel 

1 

1500 

Salinas,  Carmel 

1 

Table  4 


Complete  logging  of  optical  system  switched  off  over  the  10-day  period 


D.  SUMMARY 

The  laboratory  setup  and  test  procedures  have  been  described  in  this  chapter.  The 
configurations  and  settings  of  the  Cisco  optical  systems  and  network  management  sys¬ 
tems  are  detailed.  The  procedures  for  configuring  the  Spirent  SmartBits  6000  chassis  and 
Avalanche  software  are  described.  In  the  next  chapter,  the  relevant  probability  theory  and 
the  self-similarity  concept  are  presented. 
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IV.  PROBABILITY  THEORY  AND  SELF  SIMILARITY 


A.  CHAPTER  OVERVIEW 

This  chapter  presents  the  probabilistic  theory  of  exponential  and  Poisson  distribu¬ 
tion  which  are  important  in  the  analysis  of  data  traffic.  Some  basic  queuing  theory  equa¬ 
tions  are  also  discussed  which  are  fundamental  to  the  analysis  of  the  data  packets.  Lastly, 
the  self-similarity  concept  is  presented. 


B.  THE  RANDOM  VARIABLE  AND  PROBABILITY  DISTRIBUTIONS 

The  random  variable  is  a  mapping  of  a  set  of  elements  to  a  sample  space  by  a 
function  [19].  For  a  random  variable,  X,  the  mean  and  variance  of  the  random  variable  are 
defined  as, 

E  [X]  =  X  =  <ux  =fjxiP(xi)  (4.1) 

1=1 

\av[X]  =  a2x  =E[X2]-(E[X])2.  (4.2) 


From  the  above  statistical  equations,  an  important  quantity,  known  as  the  coeffi¬ 
cient  of  variation,  is  defined  as, 


/L 


(4.3) 


The  coefficient  of  variation  is  a  normalized  measure  of  the  degree  of  variability  of  the 
random  variable. 


In  the  field  of  queuing  analysis,  there  are  several  probability  distributions  which 
are  important.  For  the  purpose  of  this  study,  the  Poisson  and  exponential  distributions 
will  be  discussed  here  [20]. 

Consider  a  discrete  random  variable,  X,  with  an  exponential  distribution  and  char¬ 
acterized  by  the  parameter  ju  >  0,  the  mean  and  variance  are  given  by,  respectively, 


E[X]  =  I 
M 


(4.4) 
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Var[X]  =  -17. 


(4.5) 


The  exponential  distribution  is  often  used  to  model  the  interarrival  times  between 
data  packets,  or  the  service  time  of  the  data  packets.  Notice  that  the  coefficient  of  varia¬ 
tion  is  equal  to  1,  which  is  a  special  case  of  the  exponential  distribution. 

Consider  a  discrete  random  variable,  7,  which  is  Poisson  distributed  and  charac¬ 
terized  by  the  parameter  A  >  0,  the  mean  and  variance,  respectively, 


E[7]  =  A 

(4.6) 

Var[7]  =  A . 

(4.7) 

The  Poisson  distribution  is  important  because  the  arrival  rate  of  data  packets  is 
usually  assumed  to  be  Poisson  distributed  which  forms  the  basis  of  developing  the  queu¬ 
ing  theory  equations.  In  a  Poisson  process,  the  probability  of  a  packet  arriving  within  an 
interval  is  independent  of  the  arrival  of  the  previous  or  next  packet.  If  we  model  arrival 
process  as  Poisson,  the  following  equations  apply. 


Pr  {k  items  arrive  in  time  interval  T}  = 


WH*  e-AT 

k\ 


(4.8) 


E{number  of  items  arriving  in  time  interval  T}  =  AT  (4.9) 

Mean  arrival  rate  (items  per  unit  time)  =  A.  (4.10) 

Poisson  arrivals  are  also  considered  random  arrivals  as  the  probability  of  an  item 
arriving  within  a  small  interval  is  proportional  to  the  interval  length  and  independent  of 
the  time  elapsed  since  the  arrival  of  last  item. 

The  Poisson  process  is  also  related  to  the  exponential  distribution.  By  considering 
interarrival  times  of  Ta,  the  following  relationships  are  defined, 

Pr[7;  <t\  =  \-ext  (4.11) 


ek]4 

Hence,  the  arrival  rate  is  the  inverse  of  the  mean  interarrival  time. 


(4.12) 
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C.  QUEUING  THEORY  EQUATIONS 

Most  process  models  are  described  by  the  Kendall’s  notation  [21],  X/Y/N,  where  X 
refers  to  the  interarrival  time  distribution,  Y  the  service  time  distribution,  and  N  the  num¬ 
ber  of  server  in  the  system.  In  this  study,  the  M/M/1  model  is  assumed.  M/M/1  is  the 
model  notation  for  a  single-server  with  Poisson  arrivals  or  exponential  inter-arrival  times, 
and  exponential  service  times.  From  Equation  (4.18),  the  arrival  rate  is  given  by, 


E [T  ]  Mean  Interarrival  Times 


(4.13) 


As  the  mean  service  time  is  related  to  the  mean  packet  length  and  link  rate,  the 
mean  service  time  is  defined  as  [6] 


Mean  Packet  Length  (bytes)  x  8 
Link  rate  (kbits/s) 


(4.14) 


Consequently,  combining  Equations  (4.20)  and  (4.21)  gives  the  utilization  of  the 


p  =  ATs. 


(4.15) 


D.  SELF-SIMILARITY  IN  COMPUTER  NETWORKS 

Self-similarity  is  a  phenomenon  described  for  a  particular  process  which  appears 
the  same  when  viewed  at  different  magnification  of  time  scales.  Such  processes  have 
characteristics  which  are  very  different  from  conventional  telephone  traffic,  which  is  usu¬ 
ally  modeled  as  Poisson  process.  The  paper  by  Leland  et  al.  [8]  demonstrated  that 
Ethernet  traffic  is  actually  self-similar  and  that  a  Poisson  process  used  to  describe 
Ethernet  traffic  may  not  be  a  sufficient  model. 

Self-similar  processes  tend  to  exhibit  persistence  in  clustering  which  suggests  that 
clustering  occurs  at  different  time  scales  [20]  and  burstiness  of  traffic  would  occur  over 
long  periods.  This  is  in  contrast  with  the  Poisson  process  where  clustering  usually  occurs 
in  the  shorter  term  and  smoothes  out  over  the  long  term.  This  would  suggest  that  a  Pois- 
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son  arrival  will  flatten  out  over  the  long  term.  Thus  buffers  of  data  would  build  up  shortly 
and  be  cleared  over  time.  For  the  self-similar  process,  this  is  not  the  case  as  burstiness 
tends  to  prolong  over  long  periods  of  time. 

The  concept  of  self-similarity  is  often  associated  with  long-range  dependence 
(LRD)  [6].  Long-range  dependence  signifies  the  persistence  of  self-similar  processes 
which  exhibit  clustering  and  bursty  characteristics  at  all  time  scales. 


1.  Modeling  Self-Similarity,  Long-Range  Dependence  and  Heavy-Tailed 
Distributions 

In  order  to  estimate  the  self-similar  nature  of  the  data  traffic,  the  Hurst  parameter 
[20]  is  used.  It  is  a  measure  of  the  persistent  nature  of  the  self-similarity  phenomenon  and 
a  measure  of  the  long-range  dependence  of  the  process.  A  value  of  H  =  0.5  represents  an 
absence  of  long-range  dependence  and  is  usually  associated  with  Poisson  processes.  Val¬ 
ues  of  H  closer  to  1  indicate  a  greater  degree  of  persistence. 

There  are  several  approaches  in  which  the  Hurst  parameter  is  estimated,  such  as 
the  “R/S  plots”  [5].  In  this  study,  the  “Variance-Time  Plot”  method  will  be  used  [20].  The 
process  x  is  said  to  be  self-similar  if  the  aggregated  time  series  x(m>  obeys  the  following, 


Var(x(m))  -  Var^ 


(4.16) 


where  the  self-similarity  Hurst  parameter  is  given  by, 


H  =  1  — 


P 


(4.17) 


Taking  the  log  of  both  sides,  Equation  (4.16)  can  be  written  as, 

log[  Var(x(m) )]  -  log[  Var(x)]  -  J3  log  (m) .  (4.18) 

Thus,  by  plotting  log[Var(x^)]  against  log(m),  the  result  would  be  a  straight  line  of  slope 
~/3 .  Subsequently,  the  Hurst  parameter  can  be  deduced  from  Equation  (4.18). 

A  self-similar  process  is  often  referred  to  as  possessing  long-range  dependence 
(LRD).  LRD  refers  to  processes  which  have  autocovariance  that  decay  very  slowly  or 
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there  exist  finite  samples  at  larger  values  of  the  distribution.  LRD  has  the  following  prop¬ 
erty  [20], 

C(k)  ~  \k\P  as  A:  — » co,  0</?<l,  (4.19) 

where  C(k )  denotes  the  autocovariance  function  for  the  stationary  process  and  k  the  ag¬ 
gregate  time  series  for  k  >  0. 

Note  that  if  /?  is  between  0  and  1,  this  means  that  if  is  between  0.5  to  1.  Thus 
processes  which  exhibit  LRD  are  also  self-similar.  Although  larger  [3  would  lead  to 
lower  H,  i.e.,  less  self-similar,  in  this  study,  the  terms  self-similarity  and  LRD  are  used 
interchangeably. 

A  process  is  considered  to  possess  a  “heavy-tailed”  distribution  if  large  values  of 
the  random  variable  exist  with  non-zero  probabilities  [6], 


2.  Performance  Implications,  Norros  Model 

Proposed  by  Norros  [22],  for  a  given  self-similar  process  of  Hurst  parameter  H, 
the  buffer  requirement  q  is  related  to  the  utilization  p  given  by, 


^1/2(1  -H) 

(1  -pf1*-11'  ' 


(4.20) 


Using  this  equation,  the  utilization  graph  ( q  versus  p )  could  be  plotted  to  assess 
whether  the  buffer  requirements  would  escalate  at  lower  utilization  rates  due  to  high  de¬ 
gree  of  long-range  dependence  (H  closer  to  1).  This  analysis  will  be  useful  in  estimating 
the  buffer  required  for  a  particular  network  at  the  desired  utilization  rate  or  vice  versa. 


E.  SUMMARY 

This  chapter  has  presented  the  probability  theory  and  the  self-similarity  concepts 
which  are  essential  tools  required  in  analyzing  data  traffic.  In  the  next  chapter,  the  traffic 
analysis  of  the  CTM  traffic  are  analyzed  and,  using  the  concepts  presented  in  this  chapter, 
the  statistical  analysis  is  detailed. 
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V.  TRAFFIC  ANALYSIS,  PERFORMANCE  MODELING  AND 

ESTIMATION 


A.  CHAPTER  OVERVIEW 

This  chapter  presents  the  traffic  analysis  of  the  collected  SONET  management 
traffic.  A  close  analysis  is  performed  on  the  data  packets  collected  from  Ethereal  which  is 
followed  by  statistical  analysis  to  determine  the  mean  interarrival  times  and  packet  size 
of  the  different  types  of  management  traffic.  Next  the  computations  of  the  Hurst  parame¬ 
ters  are  presented  which  leads  to  the  estimation  of  link  utilization  for  the  different  types 
of  management  traffic.  Finally,  comparisons  with  the  previous  research  are  presented. 


B.  TRAFFIC  ANALYSIS  OF  SONET  MANAGEMENT  TRAFFIC 

The  SONET  management  traffic  was  collected  using  Ethereal  during  the  ten-day 
period  from  28  January  to  6  February  2005.  The  duration  of  the  ten-day  data  collection 
period  was  chosen  to  make  it  consistent  with  the  prior  research  [11,  12].  Over  the  ten-day 
collection  period,  the  total  number  of  packets  collected  and  the  respective  breakdown  of 
the  types  of  SONET  management  traffic  are  presented  in  Table  5. 


This  Study 

Previous  work 

Case  1 

Case  2 

Case  3 

Types  of  traffic 

Data  collected 

Data  collected 

Data  collected 

from  28  Janu- 

from  Ng 

from  Lim 

ary  to  6  Febru- 

(From  Ref. 

(From  Ref. 

ary  2005 

I121-) 

fill-) 

CTM  Socks 

86730 

94916 

203278 

CTM  SNMPv2 

3714 

4332 

7364 

CTM  Socks  and  SNMPv2 

90444 

99248 

210642 

CTM  Ethernet 

238659 

206694 

471103 

Others 

212904 

98138 

193333 

Total  (CTM  Ethernet  +  Others 

452563 

304832 

664436 

Table  5.  Breakdown  of  the  number  of  data  packets  collected  for  the  CTM  traffic 

and  comparison  with  previous  works 


From  the  data  packets  collected,  only  the  Socks,  SNMP  and  the  related  TCP 
packets  related  were  used  in  this  analysis.  There  were  plenty  of  packets  from  the  General 
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Inter-Orb  Protocol  (GIOP)  communications  which  is  not  relevant  to  this  study  as  they 
were  routine  database  updates  to-and-from  the  CTM  server  with  the  NEs,  although  they 
were  part  of  the  SONET  management  traffic.  The  Socks  traffic  was  due  to  the  NEs  updat¬ 
ing  their  status  information  with  the  CTM  server,  while  the  SNMPv2  traffic  was  due  to 
the  CTM  server  initiating  “GetBulk”  commands  from  the  NEs.  The  total  management 
traffic  of  Socks,  SNMPv2  and  the  related  TCP  packets  are  collectively  termed  as  “CTM 
Ethernet.” 

For  the  purpose  of  this  traffic  analysis  discussion,  Case  1  is  used  for  this  study  for 
data  collected  under  loading  with  network  disruption  conditions.  Case  2  is  used  for  data 
collected  under  loading,  as  referenced  from  [12].  Case  3  is  referring  to  data  collected  un¬ 
der  no-load  conditions  [11]. 

Looking  at  the  number  of  packets  collected  from  Case  1,  considering  that  disrup¬ 
tion  was  applied  to  the  SONET  network,  it  was  found  that  the  number  of  Socks  and 
SNMPv2  were  about  10%  less  than  that  collected  when  there  was  no  disruption.  Al¬ 
though  the  SONET  network  was  continuously  loaded  by  the  SmartBits  traffic  generator, 
the  management  traffic  appeared  to  drop  by  some  extent.  This  drop  is  due  to  the  network 
outages  when  the  ONS 15454  was  turned  off.  It  was  noted  that,  on  the  average,  the 
ONS 15454  took  about  7  minutes  to  synchronize  the  optical  circuits  after  it  is  switched 
on.  By  taking  into  consideration  of  the  outage  time  duration,  the  network  availability  was 
computed  to  be  about  97.16%.  Thus  the  network  outage  of  2.84%  has  caused  the  Socks 
and  SNMPv2  packets  to  drop  by  10%. 

When  considering  the  overall  management  traffic,  the  total  amount  of  Ethernet 
packets  was  higher  compared  to  Case  2.  This  could  be  due  to  CTM  issuing  more  health 
status  requests  to  the  NEs  that  were  offline  but  less  Socks  packets  as  the  NEs  were  down. 
The  increase  in  TCP  communications  was  about  20%  as  noted  from  the  table.  Another 
possibility  could  be  due  to  online  NEs  which  are  communicating  more  often  with  the 
CTM  server  when  one  of  the  NEs  is  down. 

Comparing  Case  1  with  Case  3,  the  management  traffic  was  significantly  lower 
by  more  than  50%.  The  consequence  of  loading  the  network  with  applied  disruption  has 
reduced  the  number  Socks  and  SNMPv2  traffic  drastically.  This  is  an  interesting  phe- 
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nomenon  as  the  main  cause  is  due  to  the  disruption.  This  is  expected  because  there  would 
be  less  Socks  and  SNMPv2  packets  generated  when  the  NEs  were  down. 


C.  STATISTICAL  ANALYSIS  AND  COMPARISONS  WITH  PRIOR  WORK 

From  the  data  collected,  the  random  variables  of  interest  are  interarrival  times  and 
the  packet  sizes.  As  the  total  number  of  packets  is  very  large,  manual  calculation  of  the 
statistics  would  be  very  tedious.  Furthermore,  in  order  to  extract  the  Hurst  parameter,  the 
variances  have  to  be  computed  for  different  aggregated  time  series  (10,  32,  100,  320  and 
1000  seconds).  To  simplify  the  process,  two  Mathcad  script  files  were  used  to  carry  out 
the  required  operations.  Both  of  these  script  files  were  developed  by  Lieutenant  James 
Young  from  the  EC4850  (Summer  2003)  class.  The  first  script  file  computes  the  mean 
and  variances  of  interarrival  times  and  packet  sizes  of  the  data  collected.  In  addition,  it 
also  computes  the  variances  for  several  aggregated  time  series  data.  The  second  script  file 
computes  the  histogram  distribution  of  the  interarrival  times  and  packet  lengths  and  out¬ 
puts  to  a  Microsoft  Excel  file,  which  is  then  plotted  to  give  the  distribution  of  the  data 
traffic. 


1.  Interarrival  Times  Distribution  Graphs 

Using  the  Mathcad  script,  the  histogram  data  was  generated,  exported  to  Excel 
and  plotted.  Figures  15,  16,  17  and  18  shows  the  interarrival  times  distributions  for  the 
loading/disruption  and  loading/no  disruption  cases. 


Interarrival  times  distribution  for  Socks  Traffic  (Loading/ Disruption) 


Interarrival  times  (s) 


Inter-arrival  Time  Distribution  for  Socks  Traffic 
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Figure  14.  Distribution  of  Socks  traffic  interarrival  times,  loading/disruption  (left), 

loading  (Right,  from  Ref.  [12].) 
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Interarrival  times  distribution  for  SNMFV2  Traffic  (Lociding/Disruption) 


Inter-arrival  Time  Distribution  for  SNMP  Traffic 


Time  (seconds) 


Figure  15.  Distribution  of  SNMPv2  traffic  interarrival  times, 

loading/disruption  (left),  loading  (Right,  from  Ref.  [12].) 


Interarrival  times  distribution  for  Socks/SNMPv2  Traffic 
(Loading/ Disruption) 


(N  (N  (N 


Interarrival  times  (s) 


Inter-arrival  Time  Distribution  for  Socks  and  SNMP  Traffic 


Time  (seconds) 


Figure  16.  Distribution  of  combined  Socks/SNMPv2  traffic  interarrival  times, 

loading/disruption  (left),  loading  (Right,  from  Ref.  [12].) 


Figure  17.  Distribution  of  Ethernet  traffic  interarrival  times, 

loading/disruption  (left),  loading  (Right,  from  Ref.  [12].) 


Figure  14  shows  that  the  Socks  traffic  exhibits  a  “heavy- tailed”  distribution.  It  is 
observed  that  Socks  traffic  with  loading  and  disruption  decays  slightly  faster  than  the 

loading  case  for  small  values  of  interarrival  times.  This  suggests  that  the  arrival  rate  is 
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slightly  smaller  in  the  case  when  the  network  is  loaded  and  disrupted.  Although  the  load¬ 
ing/disruption  case  decays  slightly  faster,  it  is  still  “heavy-tailed.”  This  suggests  that  the 
Socks  traffic  has  prolonged  burstiness.  For  the  no  disruption  case,  though,  the  tail  is 
slightly  larger  compared  to  the  loading/disruption  case. 

In  Figure  15,  the  loading/disruption  SNMPv2  traffic  exhibit  a  slight  degree  of 
“heavy-tailed”  distribution  as  opposed  to  the  loading/no-loading  case  which  resembles  an 
exponential  distribution.  Close  examination  on  the  loading/disruption  case  appears  to  de¬ 
cay  faster  than  that  of  the  loading/no  disruption  case  for  small  interarrival  times. 

In  Figure  16,  similar  observations  were  made.  For  the  combined  Socks  and 
SNMPv2  traffic,  it  is  observed  that  the  Socks  distribution  dominates  as  depicted  by  the 
similarity  between  Figures  14  and  16  for  the  loading/disruption  case.  Furthermore,  it  is 
observed  that  the  loading/disruption  case  has  a  slightly  smaller  tail  compared  to  the  load- 
ing/no-disruption  case  and  decays  slightly  faster  for  small  interarrival  times. 

Similar  observations  are  made  for  the  CTM  Ethernet  traffic  as  depicted  in  Figure 
17.  In  general,  the  loading/disruption  interarrival  time  distribution  decays  faster  but  has  a 
larger  tail  compared  to  the  no-disruption  case. 


2.  Interarrival  Times  Statistics 

Using  the  Mathcad  script,  the  statistics  of  mean,  variance  and  coefficient  of  varia¬ 
tion,  using  Equation  (4.3)  are  computed.  Tables  6,  7  and  8  tabulate  the  values  for  the 
mean,  variance  and  coefficient  of  variation,  respectively.  The  respective  values  are  com¬ 
pared  with  those  of  loading,  loading  without  disruption  and  no  loading. 


Mean,  E^a]  (s) 

Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

10.858 

8.2 

4.553 

CTM  SNMPv2 

253.581 

179.533 

120.043 

CTM  Socks  and  SNMPv2 

10.413 

7.842 

4.394 

CTM  Ethernet 

3.93 

3.213 

1.965 

Table  6.  Comparison  of  means  of  interarrival  times 
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2 

Variance  (s  ) 

Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

2356 

1630 

772 

CTM  SNMPv2 

l.lOxlO7 

4.54xl06 

6.27xl05 

CTM  Socks  and  SNMPv2 

2242 

1560 

746 

CTM  Ethernet 

821 

543 

324 

Table  7.  Comparison  of  variances  of  interarrival  times 


Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

4.471 

4.927 

6.103 

CTM  SNMPv2 

13.062 

11.863 

6.597 

CTM  Socks  and  SNMPv2 

4.547 

5.041 

6.215 

CTM  Ethernet 

7.293 

7.249 

9.159 

Table  8.  Comparison  of  coefficient  of  variation  of  interarrival  times 


From  Table  6,  it  is  observed  that  the  overall  means  for  the  loading/disruption  case 
are  higher  compared  to  those  of  the  loading  and  no-loading  cases.  This  is  expected  as  the 
average  duration  of  the  network  outages  adds  to  the  mean  interarrival  times  of  the  statis¬ 
tics.  For  Table  7,  the  variances  obtained  from  loading/disruption  case  are  higher  in  gen¬ 
eral.  This  is  expected  as  the  network  outages  introduce  some  degree  of  irregularities  into 
the  interarrival  times.  In  Table  8,  it  is  observed  that  the  loading/disruption  coefficients  of 
variations  of  the  different  types  of  traffic  are  close  to  those  of  loading.  This  might  suggest 
that  the  degree  of  variability  does  not  change  significantly  when  the  network  was  subject 
to  disruption.  In  contrast,  when  comparing  the  loading/disruption  case  to  the  no-loading 
case,  the  higher  value  for  SNMPv2  suggests  that  the  disruptive  network  has  increased  the 
variability  of  SNMPv2  traffic  significantly. 


3.  Arrival  Rates 

After  computing  the  mean  interarrival  times,  the  arrival  rates  for  the  respective 
traffic  are  computed  using  Equation  (4.13).  Table  8  shows  the  arrival  rate  comparisons 
for  the  current  work  (loading/disruption  case)  with  previous  research. 

It  is  observed  from  Table  8  that  all  arrival  rates  of  loading/disruption  case  are  all 


lower  than  those  of  loading  and  no-loading  cases.  This  is  expected  as  network  outages 
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caused  a  reduction  of  traffic  between  the  server  and  the  NE  that  was  down.  As  for  the 
CTM  Ethernet  traffic,  the  drop  in  arrival  rate  is  fairly  small,  suggesting  that  the  network 
outage  causes  little  disruption  to  the  CTM  Ethernet  traffic. 


Arrival  rates,  2  (s'1) 

Loading/ 

Disruption 

Loading  (From 
Ref.  [121.) 

No  loading 
(From  Ref.  [111.) 

CTM  Socks 

0.092 

0.122 

0.220 

CTM  SNMPv2 

0.00394 

0.00557 

0.008 

CTM  Socks  and  SNMPv2 

0.096 

0.128 

0.228 

CTM  Ethernet 

0.254 

0.311 

0.509 

Table  9.  Comparison  of  arrival  rates 


4.  Packet  Size  Distribution 

Using  the  Mathcad  script,  the  histogram  data  is  generated,  exported  to  Excel  and 
plotted.  Figures  18,  19,  20  and  21  shows  the  packet  size  distributions  for  the  load¬ 
ing/disruption,  loading  and  no-disruption  cases. 


Packet  size  distribution  for  Socks  Traffic  (Loading/Disruption) 


Packet  Size  Distribution  for  Socks  Traffic 


Figure  18.  Distribution  of  Socks  traffic  packet  sizes,  loading/disruption  (left), 

loading  (Right,  from  Ref.  [12].) 


Packet  size  distribution  for  SNMPv2  Traffic  (Loading/Disruption) 


Packet  Size  Distribution  for  SNMP  Traffic 


Figure  19.  Distribution  of  SNMPv2  traffic  packet  sizes,  loading/disruption  (left), 

loading  (Right,  from  Ref.  [12].) 
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Packet  size  distribution  for  Socks/SNMPv2  Traffic  (Loading/Disruption) 


Packet  Size  Distribution  for  SNMP  and  Socks  Traffic 


Packet  Size  (bytes) 


Figure  20.  Distribution  of  Socks/SNMPv2  traffic  packet  sizes, 

loading/disruption  (left),  loading  (Right,  from  Ref.  [12].) 


I^acket  size  distribution  for  Ethernet  Traffic  (Loading/Disruption) 
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Figure  2 1 .  Distribution  of  Ethernet  traffic  packet  sizes,  loading/disruption  (left), 

loading  (Right,  from  Ref.  [12].) 


From  Figure  18,  it  is  observed  that  both  loading/disruption  and  loading  cases  have 
similar  distribution  of  Socks  data  packets.  The  loading/disruption  case  appears  to  have 
more  packets  in  the  region  of  100-200  bytes.  In  Figure  19  of  the  SNMPv2  packet  size 
distribution,  it  is  observed  that  the  distribution  exhibits  a  heavy-tail  as  there  exists  finite 
samples  at  higher  values.  The  loading/disruption  case  has  higher  number  of  packets  in  the 
regions  of  260,  344  and  800  bytes. 

In  Figure  20  for  the  combined  Socks  and  SNMPv2  traffic,  it  is  observed  that  the 
loading/disruption  case  has  a  slightly  heavier  tailed  compared  to  loading/no-disruption 
case.  For  Figure  21,  the  same  observations  hold  for  the  CTM  Ethernet  traffic. 


5.  Packet  Size  Statistics 

The  mean,  variance  and  coefficient  of  variation  are  computed  and  shown  in  Ta¬ 
bles  10,  11  and  12,  respectively. 
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Mean  (bytes) 

Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [111.) 

CTM  Socks 

143 

172 

145 

CTM  SNMPv2 

376 

441 

455 

CTM  Socks  and  SNMPv2 

152 

184 

156 

CTM  Ethernet 

116 

125 

103 

Table  10.  Comparison  of  means  of  packet  size 


2 

Variance  (bytes  ) 

Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

27690 

35800 

21537 

CTM  SNMPv2 

62320 

61200 

2628 

CTM  Socks  and  SNMPv2 

31260 

40000 

42122 

CTM  Ethernet 

23370 

27900 

13118 

Table  1 1 .  Comparison  of  variances  of  packet  size 


Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

1.166 

1.101 

1.09 

CTM  SNMPv2 

0.664 

0.561 

1.012 

CTM  Socks  and  SNMPv2 

1.161 

1.089 

0.113 

CTM  Ethernet 

1.321 

1.334 

0.996 

Table  12.  Comparison  of  coefficient  of  variances  of  packet  size 


From  Table  10,  it  is  observed  that  the  mean  packet  size  for  the  loading/disruption 
case  is  lower  compared  to  both  loading  and  no-loading  cases  except  for  the  CTM 
Ethernet  traffic.  The  mean  packet  size  for  loading/disruption  case  is  lower  than  that  of 
loading  but  higher  than  no-loading  case.  This  phenomenon  could  be  due  to  smaller  pack¬ 
ets  been  transacted  between  the  server  and  the  NEs  or  it  could  be  as  a  result  of  more 
packets  for  the  loading/disruption  case  compared  to  the  loading  case.  As  for  Table  1 1,  the 
loading/disruption  case’s  variances  are  generally  lower  except  for  the  SNMPv2  traffic 
which  is  close  to  that  of  the  loading  case. 

For  Table  10,  it  is  observed  that  the  coefficient  of  variances  for  the  load¬ 
ing/disruption  case  is  close  to  that  of  the  loading  case.  This  suggests  that  the  network  dis¬ 
ruption  did  not  alter  the  packet  size  distribution  very  much.  But,  when  compared  to  the 
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no-loading  case,  there  is  a  significant  difference  for  the  SNMPv2  traffic  as  it  is  less  than 
1,  although  higher  than  the  loading  case’s. 


6.  Service  Times 

From  the  mean  packet  size,  the  mean  service  times  are  computed  using  Equation 
(4.14).  The  values  are  shown  in  Table  13,  along  with  the  results  from  previous  research. 
Note  that  during  the  computation,  the  link  rates  for  Socks  and  SNMPv2  are  192  kbps,  for 
the  SDCC  link,  while  that  for  the  CTM  Ethernet  traffic  is  100  Mbps. 


Mean  Service  Times,  Ts 
(ms) 

Loading/ 

Disruption 

Loading  (From 
Ref.  [121.) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

5.944 

7.161 

6.044 

CTM  SNMPv2 

15.661 

18.382 

18.967 

CTM  Socks  and  SNMPv2 

6.343 

7.651 

6.496 

CTM  Ethernet 

9.257ps 

10.021ps 

8.214ps 

Table  13.  Comparison  of  Service  Times 


It  is  of  interest  to  note  that  the  service  times  for  the  Socks  and  SNMPv2  traffic  are 
lower  compared  to  the  loading  and  no-loading  cases.  This  is  due  to  fewer  packets  sent  in 
the  network  when  one  or  two  of  the  NEs  were  down.  The  CTM  Ethernet  traffic  service 
time  is  lower  than  the  loading  case  but  higher  than  the  no-loading  case.  This  is  because 
the  CTM  server  takes  slightly  longer  to  process  the  packets  due  to  the  larger  packet  size 
compared  to  the  no-loading  case,  while  it  takes  a  slightly  shorter  time  to  process  due  to 
the  smaller  packet  size  compared  to  the  loading  case. 


7.  Link  Utilization 

Using  Equation  (4.15),  the  link  utilization  for  4  NEs  is  computed  as  shown  in  Ta¬ 
ble  14.  It  is  then  extrapolated  to  determine  the  utilization  for  2500  NEs  presented  in  Table 
15. 
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Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [111.) 

CTM  Socks 

5. 475x1  O'4 

8.736xl0'4 

1.330xl0‘3 

CTM  SNMPv2 

6. 176x1  O'5 

1.024x1  O'4 

1.580xl0-4 

CTM  Socks  and  SNMPv2 

6.092x1  O'4 

9.793x1  O’4 

1.480x1  O'3 

CTM  Ethernet 

2.356xl0'6 

3 . 1 1 7  x  1  O'6 

4. 180x1  O’6 

Table  1 4.  Comparison  of  link  utilization  for  4  NEs 


Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

0.342 

0.546 

0.830 

CTM  SNMPv2 

0.039 

0.064 

0.099 

CTM  Socks  and  SNMPv2 

0.381 

0.612 

0.926 

CTM  Ethernet 

1.472x1 0’3 

1.948x1  O’3 

2.620xl0‘3 

Table  15.  Comparison  of  link  utilization  for  2500  NEs 


From  the  results  shown  in  Table  15,  it  is  observed  that  the  effective  network  utili¬ 
zation  for  the  combined  CTM  Socks  and  SNMPv2  traffic  is  lower  compared  to  loading 
and  no-loading  cases.  Intuitively,  although  the  network  utilization  were  expected  to  be 
lower  due  to  disruption,  the  statistical  analysis  presented  has  shown  that  the  results  match 
the  initial  guess.  Therefore,  the  net  effect  of  loading  coupled  with  network  disruption  has 
decreased  the  network  utilization  further  due  to  a  combination  of  lower  arrival  rate  and 
lower  service  time  (although  lower  than  the  loading  case  but  higher  than  the  no-loading 
case). 


8.  Log-Variance  Versus  Aggregated  Interarrival  Time  and  Packet  Size 
Series  Plots 

Using  the  Mathcad  script  files,  the  variances  for  respective  aggregated  time  series 
are  generated  and  exported  to  Excel  worksheets.  The  variance  versus  aggregate  interarri- 
val  time  and  packet  size  series  plots  are  plotted  for  the  various  CTM  data  traffic.  Figures 
22  to  29  show  the  variance  plots  for  the  various  CTM  data  traffic.  Note  that  the  approxi¬ 
mate  variances  values  for  the  loading  case  are  plotted  along  the  same  respective  aggre¬ 
gates.  The  straight  line  is  fitted  to  the  loading/disruption  plots  in  order  to  extract  the  gra¬ 
dient  for  the  computation  of  the  Hurst  parameters. 
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From  Figure  22,  for  the  loading/disruption  case  of  Socks  traffic,  it  is  observed  that 
the  log-variance  values  at  higher  aggregates  of  1.5  to  3  (corresponding  to  32  to  1000)  are 
higher  by  about  0.5.  Further,  the  variance  is  higher  at  smaller  aggregated  time-series  val¬ 
ues  such  that  the  curve  has  more  of  an  exponential  decay  than  a  linear  decay.  This  im¬ 
plies  that  there  exists  a  higher  degree  of  long-range  dependence  over  the  long  term  than 
over  the  short  term. 
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Variance  Interarrival  Time  Plot  for  Socks  Traffic 
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Figure  22.  Graph  of  Variance-time  plots  for  Socks  traffic 


From  Figure  23,  for  the  loading/disruption  case  of  SNMPv2  traffic,  it  is  observed 
that  the  log-variance  values  at  aggregate  values  above  1.5  are  higher  compared  to  the 
loading  case.  At  an  aggregate  value  of  3,  the  difference  is  almost  1  which  corresponds  to 
a  factor  of  10. 
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Variance  Interarrival  Time  Plot  for  SNMPv2  Traffic 


Figure  23.  Graph  of  Variance-time  plots  for  SNMPv2  traffic 


From  Figure  24,  for  the  loading/disruption  case  of  combined  Socks/SNMPv2  traf¬ 
fic,  it  is  observed  that  the  log-variance  values  are  higher  compared  to  that  of  the  loading 
case.  Again,  the  curve  exhibits  more  of  an  exponential  decay  implying  that  there  may  be 
higher  long-term  dependence  over  longer  intervals. 


Variance  Interarrival  Time  Plot  for  SNMPv2  and  Socks  Traffic 


Aggregated  Interarrival  Time  Series  Index  (log(in) 


Figure  24.  Graph  of  Variance-time  plots  for  combined  Socks/SNMPv2  traffic 


From  Figure  25,  for  the  loading/disruption  case  of  the  CTM  Ethernet  traffic,  it  is 
observed  that  the  log-variance  value  at  aggregate  1  is  higher  by  about  1  (or  factor  of  10). 
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Variance  Interarrival  Time  Plot  for  Ethernet  Traffic 


Figure  25.  Graph  of  Variance-time  plots  for  Ethernet  traffic 


From  Figures  26  to  29,  for  the  loading/disruption  case  of  packet  size,  the  log- 
variance  values  are  very  close  to  that  of  the  loading  case.  This  suggests  that  the  packet 
size  distribution  varies  slightly  due  to  disruption.  In  Figure  29,  it  is  observed  that  the  log- 
variances  values  for  the  loading/disruption  case  are  lower  compared  to  the  loading  case. 
At  a  log  aggregate  time  series  of  1,  the  value  is  higher  by  about  0.7  (or  a  factor  of  5). 
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Figure  26.  Graph  of  Variance-packet  size  plots  for  Socks  traffic 
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Figure  27.  Graph  of  Variance-packet  size  plots  for  SNMPv2  traffic 


Variance  Packet  Size  Plot  for  SNMPv2  and  SOCKS  Traffic 


Figure  28.  Graph  of  Variance-packet  size  plots  for  combined 

Socks/SNMPv2  traffic 
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Variance  Packet  Size  Plot  for  Ethernet  Traffic 
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Figure  29.  Graph  of  Variance-packet  size  plots  for  Ethernet  traffic 


9.  Self-Similarity  Analysis  and  Hurst  Parameter 

From  Figures  22  to  29,  the  respective  gradients  of  the  straight-line  fits  were  ex¬ 
tracted  for  computation  of  Hurst  parameters.  Tables  16  and  17  present  the  Hurst  parame¬ 
ter  computed  using  Equation  (4.17)  after  extracting  the  slope  (-/?)  from  the  straight-line 
fit. 


Interarrival  Times 

Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

0.7224 

0.8073 

0.5050 

CTM  SNMPv2 

0.4730 

0.8314 

0.7024 

CTM  Socks  and  SNMPv2 

0.7338 

0.8124 

0.5108 

CTM  Ethernet 

0.5764 

0.7334 

0.6838 

Table  16.  Comparison  of  Hurst  parameters  of  interarrival  times 


Packet  Size 

Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11].) 

CTM  Socks 

0.7293 

0.8256 

0.5567 

CTM  SNMPv2 

0.4713 

0.7349 

0.9066 

CTM  Socks  and  SNMPv2 

0.7440 

0.8248 

0.6227 

CTM  Ethernet 

0.7190 

0.8430 

0.8025 

Table  17.  Comparison  of  Hurst  parameters  of  packet  size 
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On  the  Hurst  parameters  for  the  interarrival  times,  the  loading/disruption-case  val¬ 
ues  are  lower  compared  to  loading-case  values.  This  suggests  that  the  management  traffic 
has  become  less  self-similar  which  is  due  to  the  network  disruption.  As  noted  above, 
there  is  some  short-term  bias  in  these  values  which  may  be  closer  to  the  non-disruption 
case  over  the  long  term.  The  loading/disruption-case  Socks  and  the  combined 
Socks/SNMPv2  traffic  are  more  self-similar  compared  to  the  no-loading  case,  while  the 
loading/disruption-case  CTM  Ethernet  traffic  is  less  self-similar  compared  to  no-loading 
case.  This  is  consistent  with  the  earlier  analysis  of  the  interarrival  times  distribution 
graphs  as  the  higher  degree  of  the  long-range  dependence  implies  lower  J3 ,  which  means 
a  higher  H  value  by  Equation  (4.17).  It  is  of  interest  to  note  that  SNMPv2  has  a  Hurst 
value  less  than  0.5,  which  suggests  that  the  SNMPv2  traffic  is  not  self-similar. 

Similar  observations  are  made  for  the  packet  sizes.  In  general,  the  load¬ 
ing/disruption-case  packet  sizes  deceases  in  its  self-similarity  compared  to  the  loading 
case,  while  the  SNMPv2  packet  size  is  not  self-similar.  The  loading/disruption-case 
Socks  and  the  combined  Socks/SNMPv2  packet  sizes  are  more  self-similar  compared  to 
no  loading  case,  but  the  loading/disruption  case  Ethernet  traffic  is  slightly  less  self¬ 
similar  compared  to  no-loading  case. 

10.  Effects  of  Self-Similarity  on  the  Queue  Size 

To  understand  the  effect  of  self-similarity  on  the  queue  size,  the  graphs  for  q  ver¬ 
sus  p  are  plotted  for  different  Hurst  parameters  using  Equation  (4.20)  based  on  Norros’ 
model.  Figures  30  and  31  show  the  graphs  for  q  =  10  and  100,  respectively. 

From  Figure  30,  it  is  observed  that  moving  from  a  utilization  rate  of  p  =  0.38  to 
0.67,  the  queue  size  increases  by  10  fold.  In  Figure  31,  going  from  p  =  0.67  to  0.83 
causes  the  queue  size  to  increase  further  to  100.  This  is  highly  undesirable  as  more  pack¬ 
ets  are  building  up  at  the  queue  of  the  CTM  server.  Too  much  queuing  is  undesirable. 
Hence,  for  safe  operation,  the  number  of  NEs  should  not  exceed  2495.  Coincidentally, 
this  figure  corresponds  to  the  specification  that  the  CTM  server  can  manage  a  maximum 
of  2500  NEs. 
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Graph  of  Queue  Size  vs  Utilization  for  q  =  1  to  10 
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Figure  30.  Graph  of  Queue  Size  vs  Utilization  for  q  =  1  to  10 


Graph  of  Queue  Size  vs  Utilization  for  q  =  1  to  100 
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Figure  31.  Graph  of  Queue  Size  vs  Utilization  for  q  =  1  to  100 
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11.  Maximum  Number  of  Manageable  NEs 

In  the  computation  of  the  number  of  manageable  NEs,  only  the  CTM’s  combined 
Socks  and  SNMPv2  traffic  are  of  interest  as  they  occupy  the  192-kbps  SDCC  link.  It  is 
noted  that  when  p  =  0.38,  the  queue  sizes  of  all  the  data  traffic  are  less  than  1.  In  order 
to  maintain  a  queue  size  of  less  than  1  at  the  CTM  server,  the  utilization  must  not  exceed 
0.38;  therefore  the  corresponding  number  of  NEs  for  the  respective  CTM  server  traffic 
are  computed  as  shown  in  Table  18. 


Loading/ 

Disruption 

Loading  (From 
Ref.  [12].) 

No  loading 
(From  Ref.  [11]) 

CTM  Socks 

2776 

1739 

1142 

CTM  SNMPv2 

24611 

14843 

9620 

CTM  Socks  and  SNMPv2 

2495 

1552 

1027 

Table  18.  Comparison  of  number  of  NEs  for  p  =0.38 


It  is  observed  that  the  number  of  manageable  NEs  based  on  the  CTM’s  combined 
Socks  and  SNMPv2  traffic  is  2495  which  is  a  61%  increase  from  the  loading  case.  It 
should  be  noted,  however,  that  this  is  a  liberal  estimate  due  to  the  bias  of  short-term  ag¬ 
gregated  time  series  on  the  Hurst  parameter  calculation.  Prudent  operation  would  suggest 
operating  with  fewer  NEs  on  the  network. 


D.  SUMMARY 

In  this  chapter,  the  traffic  and  statistical  analysis  of  the  CTM  management  data 
packets  collected  has  been  presented.  The  statistics  of  the  interarrival  times  and  packet 
sizes  were  also  computed  and  distribution  graphs  plotted.  The  log-variance  vs.  aggre¬ 
gated  interarrival  times  and  packet  sizes  graphs  were  plotted  which  allows  the  gradients 
of  the  straight-line  fit  to  be  extracted  and  the  Hurst  parameter  computed.  Finally,  the  ef¬ 
fects  of  utilization  on  the  queue  size  were  discussed  with  the  help  of  queue  size  plots. 
From  the  statistical  analysis,  much  understanding  was  gained  on  the  nature  of  the  CTM 
traffic  under  loading  and  disruption  conditions. 

The  next  chapter  concludes  the  analysis  and  the  findings.  Future  possible  research 
areas  are  also  discussed. 
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VI.  CONCLUSION  AND  FUTURE  RESEARCH  AREAS 


A.  CHAPTER  OVERVIEW 

This  chapter  summarizes  the  traffic  and  statistical  analysis  of  the  SONET  Net¬ 
work  Management  System  CTM  server  data  traffic  and  observations.  From  the  findings 
of  the  analysis,  several  future  research  areas  are  proposed. 


B.  CONCLUSION 

The  analysis  of  the  CTM  management  traffic  has  shown  that  the  Socks  and 
SNMPv2  traffic  decreases  when  the  SONET  network  is  fully  loaded  and  disruptive 
power  failures  are  applied.  Further,  the  total  number  of  CTM  Ethernet  packets  of  the 
SONET  management  system  is  about  20%  higher  compared  to  the  amount  of  data  pack¬ 
ets  collected  when  the  SONET  network  was  fully  loaded  without  any  disruption.  This  is 
an  interesting  phenomenon  as  the  server  has  initiated  more  TCP  transactions  but  less 
Socks  and  SNMPv2  packets  in  the  event  of  disruption  within  the  SONET  network.  The 
increase  in  TCP  packets  is  probably  due  to  the  CTM  server  polling  for  the  health  status  of 
the  NEs  which  are  down.  It  may  also  be  associated  with  TCP  retransmissions  due  to  time¬ 
out  conditions.  Nevertheless,  the  total  Ethernet  traffic  is  observed  to  be  about  50%  less 
compared  to  the  case  when  the  SONET  network  is  not  loaded.  Hence,  it  is  concluded  that 
the  nature  of  the  CTM  server  traffic  is  such  that  more  Ethernet  traffic  is  generated  when 
the  NE  is  down,  while  less  Socks  and  SNMPv2  packets  are  observed  when  the  NE  is 
down. 

Further  analysis  of  the  data  packets  collected  using  statistical  methods  reveal 
more  interesting  facts  about  the  CTM  management  traffic.  The  statistical  means  of  the  in¬ 
terarrival  times  of  CTM’s  different  management  traffic  (Socks,  SNMPv2  and  Ethernet), 
were  all  higher  compared  to  the  case  when  the  network  was  not  disrupted.  The  higher 
means  are  due  to  the  time  outages  during  which  the  offline  NE  is  not  communicating 
with  the  CTM  server.  The  evaluation  of  the  coefficient  of  variation  for  the  interarrival 
times  revealed  that  the  CTM’s  different  management  traffic  vary  only  slightly  when  a 
SONET  network  is  disrupted,  even  though  the  graphs  of  the  interarrival  time  distribution 
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depicted  that  the  loading/disruption  exhibit  slightly  faster  exponential  decays.  This,  in 
turn,  suggests  that  the  arrival  rate  for  the  loading/disruption  case  is  lower  which  means 
that  mean  interarrival  times  are  higher.  This  is  consistent  with  the  higher  mean  interarri¬ 
val  times  computed. 

Although  the  SONET  network  was  fully  loaded  and  disruption  injected  into  the 
network,  the  packet  length  distributions  of  the  CTM  management  traffic  (includes  Socks, 
SNMPv2  and  Ethernet)  appeared  to  vary  very  little  as  depicted  by  the  graphs.  Again,  this 
is  consistent  with  the  close  coefficient  of  variation  values  between  the  loading/disruption 
and  loading  case.  Nevertheless,  the  mean  packet  sizes  of  the  CTM  Ethernet  traffic  was 
lower  for  the  loading/disruption  case  which  is  due  to  more  TCP  packets  generated  by  the 
CTM  server.  Interesting  enough,  the  Socks  and  SNMPv2  traffic  mean  packet  sizes  were 
lower  even  though  there  is  less  Socks  and  SNMPv2  traffic.  Thus,  it  is  concluded  that  the 
TCP  packets  generated  by  CTM  server  have  a  more  dominant  effect. 

The  self-similarity  analysis  revealed  a  more  interesting  nature  about  the  CTM 
management  traffic.  The  Socks  traffic  Hurst  value  of  0.7224  was  found  to  be  lower  than 
the  loading  case  of  0.8073,  but  higher  than  no-load  case  of  0.505.  There  is  a  bias  due  to 
the  short-term  aggregated  time  series  which  means  that  these  estimates  should  be  liber¬ 
ally  considered.  The  lower  Hurst  value  suggests  that  disruption  with  a  loaded  network  has 
reduced  the  degree  of  self-similarity  while  still  high  enough  due  to  network  loading  com¬ 
pared  to  no-load  case.  This  suggests  that  the  less  bursty  nature  of  the  Socks  traffic  is  a  re¬ 
sult  of  the  offline  NE(s)  which  is/are  not  sending  Socks  packets  to  the  CTM  server. 

On  the  self-similarity  analysis  of  the  loading/disruption  SNMPv2  traffic,  the 
Hurst  value  of  0.4730  suggests  the  absence  of  self-similarity  as  it  is  less  than  0.5.  This  is 
consistent  as  a  Hurst  value  of  0.5  or  less  indicates  the  absence  of  long-range  dependence 
which  is  apparent  in  the  SNMPv2  interarrival  time  distribution  graph.  This  also  suggests 
that  the  SNMPv2  becomes  less  bursty  over  prolonged  operation  in  an  environment  that  is 
affected  by  severe  network  outages.  This  would  mean  that  SNMPv2  operation  could 
break  down  in  the  event  of  network  outages  which  would  result  in  CTM  server  not  up- 
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dated  with  the  latest  management  information  of  the  NEs.  Thus  it  is  concluded  that  the 
CTM  SNMPv2  traffic  does  not  operate  well  in  a  network  environment  with  severe  net¬ 
work  outages. 

The  combined  Socks  and  SNMPv2  traffic  Hurst  value  was  found  to  be  lower  than 
the  loading  case  of  0.8 124,  but  higher  than  no-load  case  of  0.5 108.  This  is  similar  to  the 
Socks  traffic  case  which  suggests  that  the  Socks  traffic  has  a  more  dominant  self¬ 
similarity  nature  than  SNMPv2.  The  Ethernet  traffic’s  Hurst  value  of  0.5764  is  less  than 
both  the  loading  and  no-load  values  of  0.7334  and  0.6838,  respectively.  This  indicates 
that  the  Ethernet  traffic  has  become  less  self-similar  due  to  network  disruption.  Similar 
observations  were  made  on  the  packet-size  Hurst  values  for  the  CTM  management  traf¬ 
fic. 

The  loading/disruption  link  utilization  was  computed  as  0.381  for  2500  NEs.  This 
value  is  lower  compared  to  both  loading  ( p  =  0.612)  and  no-loading  (p  =  0.926)  cases, 
even  though  the  total  Ethernet  packets  collected  for  the  loading/disruption  case  is  more 
than  the  loading  case  while  less  than  that  of  no-load  case.  Thus,  the  total  number  of  pack¬ 
ets  collected  does  not  relate  to  the  degree  of  link  utilization  but,  rather,  statistical  methods 
have  to  be  employed  to  compute  the  resultant  utilization.  The  lower  link  utilization  sug¬ 
gests  that  SDCC  link  has  been  less  utilized  due  to  the  offline  NE. 

The  effect  of  link  utilization  on  queue  size  was  investigated  so  as  to  determine  the 
amount  of  queuing  buffer  required  at  different  utilizations.  It  was  observed  that  increas¬ 
ing  the  utilization  from  0.38  to  0.67  (corresponding  to  4400  NEs),  for  the  combined 
Socks  and  SNMPv2  traffic,  the  queue  size  would  increase  from  1  to  10.  The  queue  will 
again  be  increased  to  100  if  the  link  utilization  is  further  increased  from  0.67  to  0.83  as 
we  increase  the  number  of  NEs  to  5450.  Therefore,  even  though  the  SDCC  link  would 
achieve  link  utilization  of  0.83  for  5450  NEs,  the  queue  size  would  be  100  which  is  unde¬ 
sirable.  Therefore,  for  safe  operation,  while  adhering  to  a  queue  size  of  1  (p  =  0.38)  at  the 
CTM  server,  the  number  of  manageable  NEs  was  computed  as  2495  under  load¬ 
ing/disruption  conditions.  This  value  is  close  to  the  CISCO  specification  of  2500  man¬ 
ageable  NEs  for  the  CTM  server,  although  it  should  be  considered  aggressive  as  there  is 
some  short-term  bias  affecting  the  calculation. 
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The  effects  of  power  loading  coupled  with  power  disruptions  have  been  studied  in 
this  thesis  and  the  work  will  be  useful  for  high-speed  computer  networks  administrators. 
The  results  and  findings  of  this  thesis  will  benefit  the  SONET  network  administrators  by 
increasing  their  awareness  of  the  limitations  of  SONET  network  management  systems  so 
as  not  to  expand  the  network  beyond  2500  NEs.  They  will  also  understand  the  behavior 
of  SONET  management  traffic  in  a  power  disruption  environment  and  that  the  CTM  is 
able  to  function  in  the  disruptive  environment  simulated  in  this  thesis.  Further,  this  re¬ 
search  provides  the  ability  to  optimize  the  deployment  of  SONET  optical  systems,  based 
on  the  utilization  of  the  management  traffic  presented,  in  order  to  tackle  network  prob¬ 
lems  associated  with  network  loading  and  power  disruptions. 


C.  FUTURE  RESEARCH  AREAS 

The  traffic  and  statistical  analysis  have  allowed  the  nature  of  the  CTM  server  traf¬ 
fic  be  thoroughly  investigated  under  the  condition  when  the  SONET  fiber  network  is 
fully  loaded  and  disruption  injected.  A  number  of  future  possible  research  areas  have 
been  identified  as  follows. 

1.  Varying  the  Number  of  Network  Elements  and  Network  Topology 

As  the  current  work  is  performed  on  four  NEs  connected  in  a  ring  configuration, 
the  results  may  possibly  be  different  if  more  NEs  are  added.  It  is  proposed  that  at  least 
two  NEs  to  be  added  to  the  current  network.  With  two  additional  NEs,  a  total  of  six  NEs 
would  be  available  which  allows  all  six  of  them  to  be  connected  in  single  ring  network  or 
a  dual  ring  network.  The  results  would  be  very  useful  for  a  network  administrator  to  de¬ 
cide  on  which  configurations  optimize  the  CTM  4.6  management  system. 


2.  Performance  Analysis  of  SONET  SDCC  Link  Performance 

The  current  work  has  analyzed  the  performance  of  the  CTM  4.6  in  managing  the 
Network  Elements  under  network  loading  and  disruptive  conditions.  As  the  analysis  was 
investigated  at  the  IP  layer,  the  SDCC  link  performance  was  not  analyzed.  It  would  be  an 
interesting  research  area  to  analyze  the  physical  optical  layer  performance  to  understand 
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what  happens  to  the  SDCC  link  when  the  network  is  disrupted  and  how  the  link  recovers 
from  the  disruption. 


3.  Correlation  between  Network  Outages  and  Network  Utilization 

This  study  has  investigated  the  performance  of  the  CTM  server  traffic  under  load¬ 
ing  and  disruption.  As  the  disruption  was  simulated  randomly,  i.e.,  the  frequency  at 
which  the  NE  is  switched  off  and  the  number  of  NEs  turned  off,  further  investigation 
could  be  made  to  ascertain  whether  is  there  any  correlation  between  the  degree  of  outages 
and  statistics  or  self-similarity  nature  of  the  CTM  server  management  traffic. 


4.  Comparing  CTM  4.6  with  Third-party  Network  Management  Sys¬ 
tems 

As  SONET/SDH  is  an  open  optical  transport  standard,  there  exists  several  net¬ 
work  management  systems  on  the  market  which  claim  to  support  SONET/SDH  equip¬ 
ment.  Purchase  and  evaluation  of  third-party  SONET/SDH  network  management  systems 
to  compare  the  differences  in  performance  as  well  as  scalability  is  recommended.  Exam¬ 
ples  of  third-party  SONET/SDH  management  systems  are  the  Navis®  Optical  Manage¬ 
ment  System  (OMS),  marketed  by  Lucent  Technologies  [23],  and  the  Alcatel  1350  Man¬ 
agement  Suite  [24], 
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